Fix Makefile bare export leaking all variables to subprocesses#4653
Open
tuxerrante wants to merge 1 commit intomasterfrom
Open
Fix Makefile bare export leaking all variables to subprocesses#4653tuxerrante wants to merge 1 commit intomasterfrom
tuxerrante wants to merge 1 commit intomasterfrom
Conversation
mrWinston
requested changes
Mar 5, 2026
Collaborator
mrWinston
left a comment
There was a problem hiding this comment.
Couple of things:
- I believe sourcing the env file automatically in the Makefile is conceptually flawed. It just increases complexity of our make-targets. Targets can't assume anymore that the caller has already sourced the required env file. Also, using different env files will be more complex.
- It looks like this PR reorders stuff in the env file without reason. This makes reviewing harder and actually introduced a bug. Please make sure that the changes are actually minimal.
- This RP seems to add additional configuration to the default env file. I would like to see this in a separate PR to address these changes separately. They don't seem related to the issue ourlined in the PR title and make reviewing harder
- Adding the env file to git can cause issues overwriting existing local configuration. Also, having a file both ignored and added is pretty confusing and surprising. And both are bad for our dev tooling.
Remove `-include .env` and bare `export` which leaked every Make variable into recipe shells. Replace with a scoped `PYTHONPATH ?=` default so Python targets work without manual sourcing. Add PYTHONPATH to env.example for discoverability.
afa4a52 to
51becbd
Compare
Collaborator
Author
|
A few clarifications:
Tried with shellcheck but doesn't catch it. It sees that LOCATION is assigned somewhere in the file and considers it valid. It doesn't do order-sensitive analysis because the variable could also come from the environment. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
exportdirective from the Makefile that was exporting every Make variable into the environment of every subprocess, causing potential slowness and unexpected behavior.envfile (containing onlyPYTHONPATH) into the existingenvfile andenv.exampleWhy some contributors experienced multi-minute make invocations
The bare
exportexported all Make variables — including ones defined with recursive expansion (=,?=) containing$(shell)calls (git describe,git rev-parse,go env, etc.) — to every subprocess. Contributors with heavier shell startup (zsh + oh-my-zsh/compinit, nvm, conda) paid that cost on each$(shell)invocation. On fast setups with minimal bash the overhead was imperceptible, masking the issue.The
tunneltarget also used$(shell az ...)which ranazat Makefile parse time on everymakeinvocation, not just whenmake tunnelwas called. This is now a recipe-level$$(az ...)call.Test plan
makecommands expect you to manually source theenvfile as per the docs